Computer networks, and in particular Wide Area Networks (WANs) such as the Internet, provide opportunities for the misuse and abuse of communications traveling over the network. For example, two users (e.g., a human user and an enterprise server) communicating via the WAN may have their communications intercepted and/or altered. Also, it is possible for one user to misrepresent his, her, or its identity to another user.
Thus, there is a need for both privacy and authentication between users of the network communicating with one another. In other words, users should be able to rely on the fact that their transmissions will not be intercepted or altered, and that transmissions from someone purporting to be a particular user do in fact originate from that user.
In many secure communication applications, a seed or secret may be required in order to perform certain cryptographic operations such as encryption, decryption, authentication, etc. The secret may comprise, by way of example, a symmetric key or other secret shared by two or more entities. For example, an authentication token typically contains one or more secret values that are utilized in computing one-time password (OTP) values. A verifier or authentication server also has access to one or more secret values associated with the token. Typically, such verifiers or authentication servers have access to the same secret value or set of secret values that the token uses to generate its OTP values.
One such authentication token is the RSA SECURID authentication token commercially available from RSA, The Security Division of EMC, Bedford, Mass. The RSA SECURID authentication token can be used to provide two-factor authentication. Authorized users are issued individually-registered tokens that generate single-use authentication codes or One Time Password (OTP) values, which change based on an algorithm. For example, a time based authentication token with a 60 second interval produces different OTP values every 60 seconds. In a given two-factor authentication session, the user may be required to enter a personal identification number (PIN) plus the current OTP value from his or her authentication token. This information may be supplied to a verifier. If the OTP value determined by the verifier is valid, the user may be granted access appropriate to his or her authorization level. Thus, the OTP values are like temporary passwords that cannot be guessed by an attacker, with other than a negligible probability.
It will be known that at least some of the authentication tokens support a next code mode setting that requires the user to enter two valid authentication codes from the same token in order to authenticate to a system. Generally, the next code mode setting isn't a persistent state and is cleared once the user has successfully supplied multiple codes. The reasons for setting the token in next code mode are varied. For example, a system administrator may mark the token in next code mode in response to the user losing and then finding their token. Further, as another example, the user may have entered bad authentication codes on a number of consecutive occasions. Additionally, as a further example, the token may have fallen out of synchronization with the verifier or the authentication server due to long periods where the token hasn't been used, time server issues, etc.
For at least some authentication tokens, it is necessary for the user to enter a second valid authentication code that follows a valid authentication code for the same token within a specify validity window in order to move the token from Next Code Mode. This can be inconvenient.